In current computer systems, there often exists a need for modifying the behavior of executable code stored in a pre-existing executable file. For the purposes of this application, an "executable file" is any type of code image and is not limited to a particular type of executable file or a file with a particular file name extension. In particular, the need exists to change the behavior of an application without recompiling the application. This need is especially apparent in situations where it is impossible or too much work to recompile the application. For example, an application may be developed by a source company at one site and distributed to a third party vendor at another site. The third party vendor may wish to incorporate vendor-specific code into the application before redistributing it to an end customer. However, the third party vendor may not have access to the source code that the source company used to generate the executable file. Thus, the third party vendor cannot change and recompile the source code to generate a new executable file with the vendor-specific code.
As another example, especially relevant in today's extensive networking environments, a company may desire to put an existing application on the Internet and somehow incorporate licensing code to limit any use of illegal copies of the application. Current systems have tried various solutions to incorporate licensing code into an existing application. According to one technique, which will be referred to herein as "wrapping," a second application program (a wrapper program) is distributed on the network, which includes an encrypted version of the original application program. The wrapper program, when installed, decrypts the encrypted original application program and then proceeds to execute the original application program. To successfully decrypt the program, a legitimate end user must provide the proper licensing information to enable the decryption to operate. A security hole exists, however, in that, while the wrapping program is in the process of decrypting the original application executable file, temporary files are created to hold the decrypted program code. Once the entire original application program has been decrypted and stored in the temporary file, a "software pirate" can then make multiple copies of the original unencrypted application program in the temporary file and can distribute them illegally.
Further, use of the wrapping technique to incorporate licensing provides only limited additional security to a vendor who implements what is known as a "try and buy" licensing program. A try and buy licensing program typically distributes an application program with either limited functionality or for a limited time of use to enable a potential customer to explore the application. Functionality is typically limited, for example, by turning off a set of features. Once the potential customer is satisfied, the customer can pay for and license the application program properly. If an application program is distributed using the wrapping technique to potential customers for the purpose of a try and buy program, then, when the program is decrypted and stored in a temporary file, a software pirate can determine how to turn on the disabled features or how to remove the license expiration data. These security problems can result in the distribution of illegal copies, which are hard to detect and monitor in a global network environment.
A second technique for modifying the behavior of an existing application program directly inserts the new executable code into the executable file. Using the direct insertion method, an application developer determines where in the executable file the new code should be placed and inserts the code into the executable. After inserting the new code into the existing executable file, the application developer adjusts addresses that reference any relocatable code or data that follows the inserted code to account for the newly added code. However, it is very difficult for an application developer to determine where to insert code and to then test the entire application to ensure it works correctly. An application developer would typically need to disassemble the executable file and study the disassembled code to determine where to insert the code. Such disassembling and studying is a very time-consuming process. Furthermore, the process must be repeated for each application program, and for each version of each application program in which the code is to be inserted.
Thus, the need exists to modify the behavior of executable code stored in an existing executable file in a manner that is secure and that requires minimal testing outside the scope of standalone testing of the code that provides the modified behavior.